home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-disi-x500-survey-00.txt < prev    next >
Text File  |  1993-03-03  |  31KB  |  866 lines
  1.  
  2. IETF DISI Working Group                         Chris Weider
  3. INTERNET--DRAFT                           Merit Network, Inc
  4.                                   Russ Wright
  5.                          Lawrence Berkeley Laboratory
  6.                                 Elizabeth Feinler
  7.                                          NASA
  8.                                      October 1992
  9.  
  10.         A Survey of Advanced Usages of X.500
  11.  
  12. Status of this Memo
  13.  
  14. The authors are interested in documenting current advanced usages of X.500,
  15. particularly ones which go beyond the standard 'white pages' paradigm.
  16.  
  17.         This document is an Internet Draft.  Internet Drafts are working 
  18.         documents of the Internet Engineering Task Force (IETF), its Areas, 
  19.         and its Working Groups. Note that other groups may also distribute
  20.         working documents as Internet Drafts. 
  21.  
  22.         Internet Drafts are draft documents valid for a maximum of six 
  23.         months. Internet Drafts may be updated, replaced, or obsoleted
  24.         by other documents at any time.  It is not appropriate to use
  25.         Internet Drafts as reference material or to cite them other than
  26.         as a "working draft" or "work in progress."
  27.  
  28.         Please check the I-D abstract listing contained in each Internet 
  29.         Draft directory to learn the current status of this or any 
  30.         other Internet Draft.
  31.  
  32.         This Internet Draft expires April 7, 1993.
  33.  
  34.  
  35. Abstract
  36.  
  37. This document is the result of a survey asking people to detail their 
  38. advanced usages of X.500. It is intended to show how various organizations
  39. are using X.500 in ways which extend the view of X.500 as a 'White Pages'
  40. service.
  41.  
  42. 1. Introduction
  43.  
  44. As the use of X.500 spreads in the Internet, organizations are finding
  45. uses for it which go beyond the 'white pages' paradigm which has been used
  46. to introduce it to new users. Consequently, to document those new uses and
  47. to encourage the wider use of X.500, we sent out a survey to obtain 'advanced
  48. usages' of X.500. 
  49.  
  50. 1.1 The survey
  51.  
  52. The survey we sent out is included here for two purposes: 1) completeness, and
  53. 2) we'd like to encourage anyone who retrieves this document to send us their
  54. advanced usage for inclusion in the next revision.
  55.  
  56. If you wish to fill this out, please send it to the working group list
  57. disi@merit.edu.
  58.  
  59. _______________________________________________________________________________
  60.  
  61. Application Name:
  62.  
  63. Author(s):
  64.  
  65. Company or Institution:
  66.  
  67. e-mail address for more information:
  68.  
  69. If this is a product for public distribution, please give us the
  70.   Type: FREE, COMMERCIAL PRODUCT, or PROTOTYPE/RESEARCH
  71.   FREE             - Anyone may obtain this product at zero cost.
  72.   COMMERCIAL PRODUCT - One may purchase this product.
  73.   PROTOTYPE/RESEARCH - This product is not yet available, only a prototype.
  74.  
  75. If FREE, please give us:
  76.   * FTP and/or FTAM address (if available via FTP and/or FTAM):
  77.  
  78. If COMMERCIAL, please give us:
  79.   * Directions to obtain product:
  80.  
  81. Availability: (When will product be available?)
  82.  
  83. List of platforms product runs on:
  84. [The platform list can be general - e.g. UNIX]
  85.  
  86. Short Description (< 100 words):
  87.  
  88. Full Description (< 1 page):
  89.  
  90.         Fig. 1: Advanced Usages Survey Template
  91.  
  92. _______________________________________________________________________________
  93.  
  94.  
  95. This survey went out to all the mailing lists we could think of: 
  96. osi-ds@cs.ucl.ac.uk, disi@merit.edu, and dssig@ics.uci.edu.
  97.  
  98. 1.2 Disclaimer
  99.  
  100. Descriptions of the advanced usages were written by the implementors, and not
  101. by the members of DISI. Although DISI has worked with the description 
  102. authors to ensure readability, no guarantees can be made regarding the
  103. validity of descriptions. Caveat emptor.
  104.  
  105. 2 The Survey Responses
  106.  
  107. 2.1 Index to Responses
  108.  
  109. Application                                Page
  110.  
  111. 2.2.1  Global Time-table Information Service ..........................    3
  112. 2.2.2  Pre-Message Security Protocol         ..........................    4
  113. 2.2.3  Electronic Data Interchange           ..........................    5
  114. 2.2.4  Network Topology Information          ..........................    7
  115. 2.2.4.1  Shared Whois Information Project    ..........................    7
  116. 2.2.4.2  Network Information Project         ..........................    7
  117. 2.2.4.3  EARN's Network Directory            ..........................    7
  118. 2.2.5  Soft Pages                            ..........................    8 
  119. 2.2.6  X-Tel                                 ..........................   10
  120. 2.2.7  Xerox Clearinghouse                   ..........................   12
  121. 2.2.8  X.500 Sendmail                        ..........................   13
  122. 2.2.9  LDAP                                  ..........................   14
  123. 2.2.10 Gopher/X.500 Interface             ..........................   15
  124. 2.2.11 Transparent ODA Conversion            ..........................   16
  125. 2.2.12 X.500 and the whois protocol          ..........................   18
  126. 2.2.13 X.400 table handling                  ..........................   19
  127.  
  128.  
  129.  
  130.  
  131.  
  132. 2.2 Survey Responses
  133.  
  134. 2.2.1 Global Time-table Information Service
  135.  
  136. Application Name: Global Time-table Information Service based on X.500
  137.  
  138. Date Received: 7/1/1992
  139.  
  140. Date Last Validated: 7/1/1992
  141.  
  142. Author(s):
  143.   Jens Hofmann
  144.   Cuno Lanz
  145.  
  146. Company or Institution:
  147.   Laboratory of Computer Engineering and Networks,
  148.   Swiss Federal Institute of Technology (ETH Zurich)
  149.   Switzerland
  150.  
  151. e-mail address for more information:
  152.   c=CH; a=ARCOM; p=SWITCH; o=ETHZ; ou=TIK; s=Lanz (lanz@tik.ethz.ch)
  153.  
  154. Type:
  155.   experimental prototype; not public
  156.  
  157. FTP address: <none>
  158.  
  159. Short Description:
  160.   This application aims at integrating the time-table information services
  161.   offered by public transport providers of different scope (local, regional,
  162.   national or international) into a homogeneous and unified user interface.
  163.   X.500 is used to store the information in an autonomous and extensible way.
  164.  
  165. Full Description:
  166.   Most of the public tranport providers offer some kind of time-table infor-
  167.   mation service like printed directory, help-desk, telephone support or PC 
  168.   software. Unfortunately these services have some of the following drawbacks:
  169.   - no automatic update of data (information accuracy)
  170.   - no global availability (place independency)
  171.   - no permanent availability (time independency)
  172.   - no inter-provider service (service integration).
  173.  
  174.   X.500 may serve as a vehicle to overcome these drawbacks as follows: The 
  175.   public transport providers store the time-table information in a standardized 
  176.   format on locally managed DSAs. There is some kind of special purpose DUA 
  177.   which (1) queries the user for the input parameters (date, time, source and 
  178.   destination station) then (2) searches for the relevant paths by querying 
  179.   the involved DSAs and (3) displays the resulting time-table to the user.
  180.  
  181.   In a diploma thesis a student is developing a new data model which supports 
  182.   easy selection of source and destination station as well as fast exploring of 
  183.   the time-table information. He is implementing a prototype application onto
  184.   an existing DUA interface (based on HyperCard and running on Apple Macintosh) 
  185.   which is connected to the world-wide X.500 pilot service over DIXIE protocol.
  186.   In order to test the prototype application the time-table information of the 
  187.   Swiss national public transport company and of most of the regional providers 
  188.   around the city of Zurich is included under the branch: c=CH;o=ETH Zurich.
  189.  
  190.  
  191. 2.2.2 Pre-Message Security Protocol
  192.  
  193. Application Name:
  194.   Defense Message System Directory
  195.  
  196. Date Recieved: 7/1/1992
  197.  
  198. Date Last Validated: 7/1/1992
  199.  
  200. Author:
  201.   Bob Cooney
  202.  
  203. Company or Institution:
  204.   The Naval Computer and Telecommunications Station, Washington
  205.   and
  206.   The Defense Information System Agency
  207.  
  208. E-mail address for more information:
  209.   cooney@wnyose.nctsw.navy.mil
  210.  
  211. Type:
  212.   experimental prototype, not public
  213.  
  214. FTP address: <none>
  215.  
  216. Short Description:
  217.   The U.S. Navy will build a directory based on X.500 to support the 
  218.   distribution of Pre-Message Security Protocol security keys.
  219.  
  220. Long Description:
  221.   The U.S. Navy has been asked to build a directory service to support
  222.   the distribution of Pre-Message Security Protocol security keys.
  223.   The Pre-Message Security Protocol will provide SMTP/X.400 security
  224.   services for unclassified but sensitive mail on the Defense Data Network.
  225.  
  226.   The directory will be based on QUIPU. Proof of concept is expected by
  227.   October 1992, with initial operational capacity by October 1993.
  228.  
  229.  
  230. 2.2.3 Electronic Data Interchange
  231.  
  232. Application Name: An X.500 User Agent for Electronic Data Interchange
  233.  
  234. Date Received: 7/10/1992
  235.  
  236. Date Last Validated: 7/10/1992
  237.  
  238. Author:
  239.   Neil Weldon
  240.  
  241. Company or Institution:
  242.   Networks Group,
  243.   Computer Science Dept.,
  244.   Trinity College Dublin,
  245.   Ireland
  246.  
  247. e-mail address for more information:
  248.   omahony@cs.tcd.ie
  249.   nmweldon@vax1.tcd.ie
  250.  
  251. Type:
  252.   Research product and not for public distribution
  253.  
  254. FTP address: <none>
  255.  
  256. Short Description:
  257. The Directory is used to assist in solving the 'first order' problem
  258. associated with Electronic Data Interchange (EDI). EDI is the transfer
  259. of trade documents between application processes in a processable form. 
  260. The 'first order' problem describes the agreements that two organizations 
  261. must come to regarding capabilities and preferences, before using EDI.
  262.  
  263. To solve this problem we defined object types to allow the storage of
  264. product catalogues within the Directory, as well as information about
  265. the EDI readiness of trading partners: addresses, preferences and EDI
  266. capabilities.
  267.  
  268. Full Description:
  269. Electronic Data Interchange (EDI) is the means by which organizations 
  270. exchange trade related documents between application processes in an 
  271. format which may be processed electronically.
  272.  
  273. Before using EDI an organization must establish a series of goals and 
  274. objectives, to establish what type of documents they wish to be able to
  275. transmit (invoices, purchase orders etc.) and what their communication
  276. requirements are. Each of these time consuming and tedious steps is 
  277. usually done in conjunction with trading partners where these agreements 
  278. regarding EDI capabilities and preferences must be made.
  279.  
  280. To solve this 'first order' problem (the need to come to agreements with 
  281. other organizations before trading using EDI takes place) we defined object 
  282. types to allow the storage of product catalogues within the Directory. The 
  283. Directory may also convey information regarding the EDI readiness of trading 
  284. partners: addresses, preferences and EDI capabilities.
  285.  
  286. Using an experimental User Agent based on Pod which was developed at Brunel 
  287. in the UK, trade documents may be built up by selecting products from the
  288. stored catalogues. These documents are then encoded as an EDI Interchange
  289. after the Directory has been queried about addresses etc.
  290.  
  291. The current object types are very basic and may only convey the minimal 
  292. amount of information necessary. We are now in the process of extending 
  293. this further to a full product class hierarchy which is being based on 
  294. information that may be sent within an EDI trade document using the EDI 
  295. standard document syntax EDIFACT.
  296.  
  297. By using the Directory as a repository for product information to aid in 
  298. EDI the catalogues become available worldwide. They may be replicated at 
  299. various nodes, and the updating and propagation of changes to slave copies 
  300. becomes trivial.
  301.  
  302.  
  303. 2.2.4 Network Topology Information
  304.  
  305.  
  306. There are three projects in this area; Merit Network's Shared Whois Information
  307. Project, Thomas Johannsen and Mark Knopper's Network Information project, and
  308. EARN's Network Directory.
  309.  
  310. 2.2.4.1 Shared Whois Information Project
  311.  
  312. Information on this is not yet available.
  313.  
  314. 2.2.4.2 Network Information Project
  315.  
  316. Information on this is not yet available.
  317.  
  318. 2.2.4.3 EARN's Network Directory
  319.  
  320. Application Name: Ditnet/EARN Network Directory
  321.  
  322. Date Received: 7/7/1992
  323.  
  324. Date Last Verified: 7/7/1992
  325.  
  326. Author(s):
  327.   Peter Sylvester
  328.  
  329. Company or Institution:
  330.   Inria Rocquencourt - France
  331.  
  332. e-mail address for more information:
  333.   peter.sylvester@inria.fr
  334.  
  335. Type: FREE (data owned by EARN/Bitnet)
  336.  
  337. Short Description:
  338.   The EARN/Bitnet Network database consists of descriptions of all
  339.   participating members, network nodes, adminstrators, and topology
  340.   information. This database commonly known as BITEARN NODES is being
  341.   made available through x.500.
  342.  
  343. Full Description:
  344.   A full description of the contents of the EARN/Bitnet database
  345.   can be found in some EARN internal document which is available
  346.   as a file BITEARN NODES from any NETSERV in EARN/Bitnet. The contents
  347.   of this file is mapped into an X.500 subtree containing descriptions
  348.   of network nodes, adminstrational personnel, and topology information.
  349.   
  350.   The first version of the directory subtree will be created using 
  351.   a simple textual mapping to a flat directory tree using private attributes.
  352.  
  353.  
  354. 2.2.5 Soft Pages
  355.  
  356. Application Name: Soft Pages
  357.  
  358. Date Received: 9/25/1992
  359.  
  360. Date Last Validated: 9/25/1992
  361.  
  362. Author(s):
  363.   Thomas Johannsen
  364.   Glenn Mansfield
  365.  
  366. Company or Institution:
  367.   AIC Systems Laboratory,
  368.   Tohoku University Sendai
  369.  
  370. e-mail address for more information: 
  371.   spp-support@aic.co.jp
  372.  
  373. Type:
  374.   Intended for public distribution, not yet public
  375.  
  376. FTP address: <none>
  377.  
  378. Short Description:
  379.   A file name look-up services for anonymous ftp servers, provides ls -lR 
  380.   information and ftp server address. Additionally, the nearest ftp site 
  381.   (from user's site) which holds the requested file is chosen.
  382.  
  383. Full Description:
  384. With  the growing  of  number and size   of  electronic  archives  for
  385. documents,    programs  and the   like,   the problem   of finding and
  386. retrieving a specific file becomes more and more complex. Furthermore,
  387. bandwidth in the Internet is still limited. Users should be encouraged
  388. and supported to do local ftp sessions as often as possible instead of
  389. getting everything from the other end of the world (i.e. the net).
  390.  
  391. The Soft Pages Project  combines  an Archie-like file look-up  service
  392. with network  configuration knowledge.  A dedicated User Agent gives a
  393. suggestion how to  retrieve a document in  a network traffic optimized
  394. manner.
  395.  
  396. Basically, Directory information  introduced by Soft  Pages falls into
  397. two parts: A file information part and a network configuration part.
  398.  
  399. The  file information part  describes objects  and attributes for file
  400. servers and their contents. For each file server, names and attributes
  401. of its files are stored and updated periodically. This provides global
  402. access to Archie-like information for all registered file servers and,
  403. furthermore, opens the way to store document description together with
  404. the file name.  Thus, document search is  not restricted  to file name
  405. matches but might be run for keywords as well.
  406.  
  407. The  network  configuration   part provides  information   on networks
  408. (subnetworks), nodes and  lines  in   the  Internet. Furthermore,   IP
  409. numbers can   be mapped  to  network and  node objects. In   order  to
  410. evaluate  file server sites, Internet  (site  to site) connections are
  411. given  a cost index and then  alternatives are compared  by their cost
  412. index. Cost index is a calculated parameter representing properties of
  413. a  connection like speed, average   traffic, charges etc. where values
  414. for the latter are hold as attributes to line objects.
  415.  
  416. If a document is stored at two or more sites, the site with the lowest
  417. cost index  (which naturally will  be the "nearest"  in network terms)
  418. will  be chosen  for retrieval.   A  Soft  Pages  User Agent basically
  419. interacts with the Directory for finding a pointer to the  "best" copy
  420. of a file wanted by a user.
  421.  
  422.  
  423.  
  424.  
  425.  
  426. 2.2.6 X-Tel
  427.  
  428. Application Name: X-Tel's advanced applications
  429.  
  430. Date received: 7/1/1992
  431.  
  432. Date last verified: 7/1/1992
  433.  
  434. Author(s):
  435.   Colin Robbins
  436.   Julian Onions
  437.   Graeme Lunt
  438.  
  439. Company or Institution: X-Tel Services Ltd.
  440.  
  441. e-mail address for more information:
  442.   x500@xtel.co.uk
  443.  
  444. Type: 
  445.   Commercial Products / Ideas
  446.  
  447. Short Descriptions:
  448.  
  449. 1)  Product Information.   Products that have DUA facilites built in
  450. have a "latest info" button or other request method.  When "pressed" a
  451. well known node below the X-Tel part of the tree is read.  The
  452. attributes contain descriptions of the latest version of the software,
  453. new features etc.
  454. If you decide you would like the new version, a second read obtains 
  455. the information required for a template order form.
  456.  
  457. 2)  BUG Status.  As above, but obtains details of known bugs in the
  458. version of software you are running.
  459. (If only we could find a way of putting fixes in, and automatically
  460. updating the software itself!)
  461.  
  462. 3)  X-Terms.   We have a conferencing product, allowing X users to
  463. "talk" and share windows.   The problem is identifying which X
  464. Terminal device a particular user is currently on.  One solution we
  465. are using is modify a users directory entry during login to say which
  466. X display they have logged into.  The conference can the query the
  467. directory, and open windows on the appropriate device.
  468. The directory is also used to store details of current conferences, so
  469. new delegates can join the conference easily.
  470.  
  471. 4)  Organisation browsing.  There are a rich set of attributes about
  472. people and their roles stored in the directory.  We have a special
  473. purpose DUA that exploits this information, and presents information
  474. on who manages who, who is secretary for who etc.
  475. This is very useful when combined with the search ACL mechanism
  476. defined in OSI-DS 21 as different views can be given to different
  477. catergories of users.
  478.  
  479. 5)  MHS use of directory.   The directory is use to store MHS routing
  480. information (as per the MHS DS working group documents)
  481.  
  482. 6)  Mail Lists.   Details of mailing lists are stored in the
  483. directory.  With careful use of access control, users can be given
  484. access so that they can subscribe and unsubscribe themselves to/from a list.
  485.  
  486. 7)  Details of restuarants in the Nottingham area are stored in the
  487. directory!
  488.  
  489. 8)  We plan to use the directory as a rendevuz for a multi-user
  490. adventure game.   Each "room" will be a different entry, and modify
  491. operations will be used to pick up and put down objects!
  492.  
  493. The next two are "advanced" features of our DUA, they may not be
  494. considered relevant to this document!
  495.  
  496. 9)  Templates.   The directory is used to store template entries.  Our
  497. DUA then uses this template when adding new users.  Very useful, as a
  498. number of default attributes can be set.
  499.  
  500. 10)  Editors.  Special purpose editors for a number of complex
  501. attribute syntaxes are built in to our DUAs.  This includes QUIPU
  502. ACLs, and X.400 OR Addresses.
  503.  
  504.  
  505.  
  506. 2.2.7 Xerox Clearinghouse
  507.  
  508. Application Name: Clearinghouse Interface
  509.  
  510. Date Received: 7/1/1992
  511.  
  512. Date Last Validated: 7/1/1992
  513.  
  514. Author(s):
  515.   Margaret Avino
  516.  
  517. Company or Institution: 
  518.   Xerox Corporation
  519.  
  520. e-mail address for more information
  521.   mavin.cin_ops@xerox.com
  522.  
  523. Type:
  524.   Early Design/Implementation stages
  525.  
  526. Short Description:
  527.  
  528.   X.500 DSA interface to XNS (Xerox Network Services) Clearinghouse 
  529.   directory to provide access to Xerox Corporation's Clearinghouse via X.500 
  530.   DUAs.
  531.  
  532. Full Description:
  533.  
  534. Xerox uses the XNS network protocol suite to provide Mail, Filing, Directory,
  535. Authentication, etc. network services for the installed based of 45,000+ Xerox
  536. workstations.  The Directory is based on the XNS Clearinghouse protocol which
  537. is similar to X.500 in that it contains objects which have properties
  538. (attributes) and is a fully distributed, replicatable directory.  The searching
  539. capabilities of the Clearinghouse protocol are not as robust as the X.500
  540. search operation and the physical structure of the original database is not
  541. amenable to complex searches as it could be if it were stored in a relational
  542. database.
  543.  
  544. The first piece of this project is to transfer the data into an Oracle
  545. relational database and create a new Clearinghouse server which accesses the
  546. oracle database and is a full fledged member of the Clearinghouse, sending and
  547. receiving updates to other servers using the XNS Clearinghouse protocol.  This
  548. will allow powerful SQL queries to be performed on the data which will provide
  549. some very desired functionality such as:  list all of the Distribution Lists of
  550. which this name is a member.
  551.  
  552. To build on the new database, we are probing the implementation of an X.500 DSA
  553. interface to the Oracle Clearinghouse Directory.  This would allow X.500 DUAs
  554. to access the data and utilize the powerful search operations.  It will require
  555. the definition of one or more new object classes and several new attributes and
  556. some thought about the appropriate schema.
  557.  
  558.  
  559.  
  560. 2.2.8 X.500 Sendmail
  561.  
  562. Application Name: X.500 Sendmail
  563.  
  564. Date Received: 9/25/1992
  565.  
  566. Date Last Verified: 9/25/1992
  567.  
  568. Author(s):
  569.   Tim Howes
  570.  
  571. Company or Institution: 
  572.   University of Michigan
  573.  
  574. e-mail address for more information:
  575.   x500@umich.edu
  576.  
  577. Type: 
  578.   FREE
  579.  
  580. FTP address: terminator.cc.umich.edu
  581.  
  582. Directions to obtain product:
  583.   get x500/sendmail-5.65.x500.tar.Z
  584.  
  585. Short Description:
  586.   Modifications to sendmail-5.65 to do X.500 lookups.
  587.  
  588. Full Description:
  589.   
  590.   We have modified sendmail-5.65 so that it does X.500 lookups, returning
  591.   the value of a user's rfc822Mailbox attribute. It handles multiple
  592.   matches by sending a message containing the choices back to the sender.
  593.   If the user has no email address in X.500, the sender is sent a message
  594.   containing postal and phone information on the user. Both exact and 
  595.   approximate matching is supported.
  596.  
  597.  
  598.  
  599. 2.2.9 LDAP
  600.  
  601. Application Name: LDAP
  602.  
  603. Date Received: 9/29/1992
  604.  
  605. Date Last Verified: 9/29/1992
  606.  
  607. Author(s):
  608.   Tim Howes
  609.  
  610. Company or Institution: 
  611.   University of Michigan
  612.  
  613. e-mail address for more information:
  614.   ldap-support@terminator.cc.umich.edu
  615.  
  616. Type:
  617.   FREE
  618.  
  619. FTP address: terminator.cc.umich.edu
  620.  
  621. Directions to obtain product:
  622.   get x500/ldap-2.0.tar.Z
  623.  
  624. Short Description:
  625.   LDAP is the Lightweight Directory Access Protocol. It provides lightweight
  626.   TCP/IP-based access to X.500 services. This implementation includes a server,
  627.   client API library, and sundry client programs.
  628.  
  629.  
  630. 2.2.10 Gopher/X.500 Interface
  631.  
  632. Application Name: go500, go500gw
  633.  
  634. Date Received: 9/29/1992
  635.  
  636. Date Last Verified: 9/29/1992
  637.  
  638. Author(s):
  639.   Tim Howes
  640.  
  641. Company or Institution:
  642.   University of Michigan
  643.  
  644. e-mail address for more information:
  645.   x500@umich.edu
  646.  
  647. Type: 
  648.   FREE
  649.  
  650. FTP address: terminator.cc.umich.edu
  651.  
  652. Directions to obtain product:
  653.   get x500/ldap-2.0.tar.Z
  654.  
  655. Short Description:
  656.   go500gw is a general gopher to X.500 gateway server. go500 is a gopher
  657.   index server to X.500 gateway server. Both programs allow gopher users
  658.   to access X.500.
  659.  
  660. Full Description:
  661.   go500gw allows users to browse through the X.500 directory information
  662.   tree as if it were in gopher space. It also allows searching at each point
  663.   at each point in the tree. go500gw makes some reasonably intelligent
  664.   assumptions about what a user is searching for based on their position
  665.   in the tree and what they type, so users do not have to know much of
  666.   anything about X.500. go500 appears in gopher space as a single gopher
  667.   index search server, and searches a specific subtree of the X.500 namespace.
  668.   Both programs use the LDAP protocol to access X.500 and are distributed with
  669.   the LDAP distribution.
  670.  
  671.  
  672. 2.2.11 Transparent ODA Conversion
  673.  
  674. Application Name: Transparent ODA Conversion
  675.  
  676. Date Received: 7/16/1992
  677.  
  678. Date Last Verified: 7/16/1992
  679.  
  680. Author(s):
  681.   MacFarland Hale (MITRE Open Systems Group)
  682.  
  683. Company or Institution:
  684.   The MITRE Corporation
  685.  
  686. e-mail address for more information:
  687.   machale@mitre.org
  688.  
  689. Type:
  690.   Not Yet Available
  691.  
  692. Short Description:
  693. Plan to use X.500 in conjunction with X.400 and Open Document Architecture
  694. (ODA) to provide transparent translation of compound documents between a sender
  695. and one or more recipients.
  696.  
  697. Full Description:
  698. In the future, MITRE would like to combine X.500, X.400 and Open Document
  699. Architecture (ODA) to automate the conversion of compound documents in such a
  700. way that the users need not know about ODA or even that the conversion is
  701. taking place.  This will require new and/or updated X.400 products.
  702.  
  703. A preferred compound document format (e.g., Microsoft Word, FrameMaker, etc.)
  704. for each user is stored in the X.500 directory.  Each X.400 Message Transfer
  705. Agent (MTA) host also houses converters between each such format and the Open
  706. Document Interchange Format (ODIF).
  707.  
  708. A user (sender) creates a document with his or her preferred compound document
  709. editor.  Ideally, the editor software will have a link (e.g., button or
  710. pull-down menu) to the X.400 User Agent (UA).  The user invokes the X.400 UA
  711. (either using this link, or outside of the editor software) to send the
  712. document as an X.400 message to one or more recipients.  Next, the document may
  713. need to be converted to ODIF, and this may be done in one of two ways.
  714.  
  715. Preferably, the X.400 MTA will be responsible for the ODIF conversion.  The UA
  716. must somehow be told what format the original document is in.  This may be done
  717. via the UA invocation from inside the editor, via a UA configuration file, by
  718. examining the filename extension, etc.  It then tags the document to indicate
  719. the document's original format using one of the body parts: "Bilaterally
  720. Defined" (body part 14), "Nationally Defined" (body part 7) or "Externally
  721. Defined" (body part 15).  The UA then sends the message, and the MTA interprets
  722. the tag to determine the document's format.
  723.  
  724. For messages internal to MITRE, the MTA will look up the recipient's preferred
  725. document format.  If it is different than the sender's format, the MTA calls
  726. the appropriate ODIF converter and sends the message.  If the recipient's
  727. preferred format is the same as that of the document being sent, then no
  728. conversion is performed.  For messages going outside MITRE, the document is
  729. always converted to ODIF.  The user may prevent this by specifying that the
  730. enclosed document is not to be converted, in which case the UA simply sends the
  731. document in binary form with no special tag.
  732.  
  733. Alternatively, the UA may do the conversion.  As above, the UA must be told the
  734. document's original format.  The UA may then call the appropriate local ODIF
  735. converter, and then send the message.  There are some disadvantages to this
  736. approach: 1) ODIF converters must be purchased for and maintained on many more
  737. hosts; 2) the document is always converted to ODIF (unless the UA accesses the
  738. directory, but...); 3) conversion overhead could be traumatic on a small PC.
  739.  
  740. At each recipient host, the X.400 MTA catches the incoming message, recognizing
  741. the contents as ODIF.  It then looks up the recipients' preferred compound
  742. document formats, calls the appropriate converters to translate the contents,
  743. and then delivers the messages to the recipients.  If the incoming message
  744. contains one of the format tags described above, then no conversion is
  745. performed (since the document is not in ODIF).
  746.  
  747. Please note that MITRE is a not-for-profit organization.  We will not produce
  748. commercial products to support this scenario, but we are anxious to encourage
  749. and work with companies interested in doing so.
  750.  
  751.  
  752. 2.2.12 X.500 and the whois protocol
  753.  
  754. Application Name: Phone Book
  755.  
  756. Date Received: 7/15/1992
  757.  
  758. Date Last Verified: 7/15/1992
  759.  
  760. Author(s):
  761.   Steven Schoch
  762.  
  763. Company or Institution: 
  764.   NASA Ames Research Center
  765.  
  766. e-mail address for more information:
  767.   schoch@sheba.arc.nasa.gov
  768.  
  769. Type:
  770.   FREE, see Steve
  771.  
  772. Short Description:
  773.   On-line edition of our phone book, using X.500 for storage and retrieval.
  774.  
  775. Full Description:
  776.         Phone Book is a user application which communicates using the
  777. Internet whois protocol.  It is listed in the Internet Resources Guide
  778. as such.  The latest incarnation, however, does not make use of a flat
  779. file -- it gets information from a DUA that performs conversions between
  780. information received via DAP and the format that users expect to get back
  781. from our Phone Book queries.  The change to X.500 has allowed us to supply
  782. additional data such as E-mail address which do not normally appear in the
  783. phone book.  The fields supplied in response to a query include:
  784.  
  785.         Name
  786.         Telephone Number
  787.         Mail Stop
  788.         Office Number
  789.         Organizational Affiliation (either a NASA organization code or a
  790.                 contractor name)
  791.         E-mail address
  792.  
  793. Queries may be made on any of the fields specified, with the office being
  794. divided into building and room components.  A sample lookup might be:
  795.  
  796. trident:297-->phbook yee
  797. Name                        Phone    M/S     Office    Organization
  798. --------------------------- -------- ------- --------- -----------------------
  799. Arnold M. Yee                 4-4315 258-6   N258/134  COMPSCICOR    
  800. Cindy Yee                            226-3   N226/105  CALSPAN       
  801.                                      cyee@ames.arc.nasa.gov                    
  802. David H. Yee                  4-4106 213-8   N213/256  EEF           
  803.                                      david_yee@qmgate.arc.nasa.gov             
  804. Dr. Helen M C. Yee            4-4769 202A-1  N202A/216 RF            
  805. Harry Yee                     4-6557 213-2   N213/101F EES           
  806. Peter Edmond Yee              4-3812 233-18  N233/240  EDC           
  807.                                      yee@atlas.arc.nasa.gov                    
  808. Robert Yee                    4-4122 T041-3  TA20/155  SFA           
  809.                                      robert_yee@qmgate.arc.nasa.gov 
  810.  
  811. 2.2.13 X.400 table handling
  812.  
  813. Application Name: X.400 table handling
  814.  
  815. Date Received: 7/15/1992
  816.  
  817. Date Last Verified: 7/15/1992
  818.  
  819. Author(s):
  820.   Julian Onions
  821.   Colin Robbins
  822.  
  823. Company or Institution: 
  824.   X-Tel Service Limited,
  825.   Nottingham, England
  826.  
  827. e-mail address for more information:
  828.   jpo@xtel.co.uk
  829.  
  830. Type:
  831.   FREE, not yet available to the general public
  832.  
  833. Short Description:
  834.   Implementation of the work of the IETF MHS-DS group. The goal is to put X.400
  835. tables into X.500 in order to facilitate gateway and routing functions.
  836.  
  837. Full Description:
  838.   See the Internet drafts for MHS-DS. NASA Ames Research Center is 
  839. participating in the testing and development of the next release of the PP
  840. message handling software. The latest update (alpha test) contains usage
  841. of X.500 by X.400 for RFC 822<->X.400 gatewaying, as well as hooks for X.400
  842. intelligent routing. Use of X.500 to eliminate static tables will greatly
  843. improve the ability to maintain the information necessary for mail gatewaying
  844. and routing, while making it easier to keep this data current and well
  845. distributed.
  846.   
  847.  
  848.  
  849. 3 Author's addresses
  850.  
  851.   Chris Weider, clw@merit.edu
  852.   2901 Hubbard, Pod G
  853.   Ann Arbor, MI 48105
  854.   (313) 747-2730
  855.  
  856.   Russ Wright
  857.   Lawrence Berkeley Laboratory
  858.   1 Cyclotron Road
  859.   Berkeley, CA 94720
  860.   (415) 486-6965
  861.   wright@lbl.gov
  862.  
  863. 4 Expiration Date
  864.   
  865. This Internet Draft expires April 7, 1993.
  866.